Amiga Plus 1995 #2

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Plus 1995 #2 / Amiga Plus CD - 1995 - No. 2.iso / internet / faq / englisch / unixemailsoftsurvey < prev next >

Wrap

Text File | 1995-04-11 | 78.9 KB | 1,719 lines

Archive-name: mail/setup/unix/part1 Last-modified: Thu Jan 26 01:28:19 EST 1995 UNIX EMail Software - a Survey Chris Lewis clewis@ferret.ocunix.on.ca [and a host of others - thanks] Copyright 1991, 1992, 1993, Chris Lewis Redistribution for profit or altered content/format prohibited without permission of the author. Other redistribution must contain this copyright notice and attribution. Changes are marked with a preceding "|". You can skip to them by typing g^| in (most) newsreaders. Note: this FAQ has been formatted as a digest. Many newsreaders can skip to each of the major subsections by pressing ^G. Please direct comments or questions to mailfaq@ferret.ocunix.on.ca - note Reply-to: line - automatic if you reply to this article. Many changes made in the second and third parts. ------------------------------ Subject: Introduction Configuring electronic mail systems can be quite a complicated subject. Often far more complicated than, say, setting up a Usenet news feed. This is because, unlike news, email is expected to traverse multiple types of networks using their own protocol, whereas, Usenet news tends to be a single protocol supported by hook or by crook on different networks. This document is intended for system administrators who need to know how to set up their UNIX systems for email communication with the outside world. It is intended for the email-naive SA who gets more than a little confused by the acronyms, RFC's and plethora of software. This is intended to be a general survey of the software available, so I won't spend too much time on some of the details. Most of the available software comes with documentation that can explain things much better than I can. Additional detail can be obtained from several sources, such as: Quarterman, John S.: "The Matrix -- Computer Networks and Conferencing Systems Worldwide", Digital Press 1990, (Order No. EY-C176E-DP), ISBN 1-55558-033-5. Adams, Rick and Frey, Donnalyn: !%@:: A Directory of Mail Addressing and Networks, 3rd Ed., O'Reilly & Associates 1993, Provides a good reference for people seeking information on how to access the various email networks. ISBN 1-56592-031-7. Kehoe, Brendan P.: Zen and the Art of the Internet: A Beginner's Guide, Second Edition, Prentice Hall 1992, ISBN 0-13-010778-6. Edition 1 is available via FTP on cs.widener.edu in the tar file zen-1.0.tar.Z. [I think] Krol, Ed: The Whole Internet: User's Guide & Catalog. First edition, O'Reilly & Associates Sept. 1992. ISBN: 1-56592-025-2. Very good introduction to the Internet, history, facilities, uses, services, etc. I learned a lot. Albitz, Paul & Liu, Cricket: DNS and BIND, First edition, O'Reilly & Associates, October 1992. ISBN: 0-56592-010-4. Describes in great detail everything from what a domain is, to how to install and configure BIND. A *MUST* for people setting up large networks, or connecting machines to the Internet. It has become mandatory reading for network administrators in a large corporation for good reason. Costales, Bryan and Allman, Eric and Rickert, Neil: Sendmail. O'Reilly & Associates, Nov (?) 1993. ISBN 1-56592-056-2 (ISBN from galley proof, which I've had a preview of). An absolute necessity for anyone diving into the configuration of sendmail. The material is presented in a very clear form, and is quite exhaustive in its coverage. Perhaps a bit too wordy and overlong, but that's a more than welcome contrast to previous documentation (or lack thereof) on sendmail. Further, this is primarily oriented towards UNIX email systems. This is unfortunate, because it would be nice to have a general document covering email in all of its forms. However, each operating system tends to have radically different email mechanisms, so it would be difficult to do justice to any other environment. It seems more useful to cover one environment well here, and have companion documents for other environments. Speaking of which, why hasn't anybody else stepped in to do FAQs on other environments? Like DOS, Mac etc. And finally, this document is not intended to be pedantically correct. Knowledgeable readers will know that I'm glossing over a lot of detail, and absolute precision has been balanced against readability and effectiveness in helping people get going. ------------------------------ Subject: Layout This FAQ is laid out in the following sections: + An overview of how mail systems go together. + A glossary of the important terms to know. + A list of general do's and don'ts of mail systems. + Configuration Issues + Several suggested mail configurations. + General overviews of specific software. ------------------------------ Subject: Electronic mail - A General Overview of Structure Electronic mail generally consists of three basic pieces: 1) The link level transport - which could be UUCP, TCP/IP, or a host of others. We'll call this the "transport medium" (TM) 2) the "Mail Transport Agent" (MTA) which is responsible for transporting mail from source to destination, possibly transforming protocols, addresses, and routing the mail. The MTA often has several components: - Routing mechanisms - Local delivery agent (LDA) - Remote delivery agent Many MTA's have all of these components, but some do not. In other cases, it is possible to replace certain components for increased functionality. 3) The "User Agent" (UA) is the user interface - the software that the user uses to read his mail, sort things around in folders, and send mail. Sometimes called "Mail User Agent" (MUA). ------------------------------ Subject: Glossary Rather than alphabetic, this glossary tends to group terms referring to similar functionality together. Transport Medium: UUCP (Unix to Unix Copy Program): Back in the mists of time, UNIX systems communicated only over RS232 serial lines, usually over modems. UUCP is a suite of programs developed back in the early 70's to provide this communications link. All that UUCP does is transfer files from one system to another. There is an additional mechanism where one system can direct the destination system to run a file through a specific program. Electronic mail in UUCP is simply requesting the destination machine to run "mail" on a data file. UUCP communicates by means of "protocols", the most common being "g", a method for transmission of data over telephone lines and ensuring that the data is not corrupted. There are several other protocols, none universally available, and most oriented towards communication media other than telephone voice lines (such as dialup X.25, PAD X.25, or LAN connects). UUCP operates over fixed system-to-system links, so sending mail from one system to another often has to traverse other intermediate systems. TCP/IP (Transmission Control Protocol/Internet Protocol): TCP/IP is a protocol that allows any system on a network to talk "directly" to any other, by passing packets of information back and forth. TCP/IP (and its later relative OSI) is usually used over networks built on top of Ethernet, Token-Ring, Starlan and other LANS. SMTP: Or, "Simple Mail Transfer Protocol", is the communications protocol used most commonly over TCP/IP links in UNIX environments for mail. SMTP usually operates directly between the source and destination machines, so intermediate machines don't get involved (except for gateways, see below). SMTP is usually part of the MTA. SLIP (Serial Line Internet Protocol): SLIP is an implementation of TCP/IP designed for use over RS232 serial lines (ie: modems). The other difference is that some SLIP implementations have the ability to "dial the phone" to make a connection for a specific transfer, whereas LAN TCP/IP is physically continuously connected. You'd also need TCP/IP to run a SMTP mail connection. PPP (Point-to-Point Protocol): A successor to SLIP. X.25/X.29: X.25 is a packet switched data network which is usually half-duplex. In this context, it's really an alternative to dialup over voice telephone lines with modems. X.25 is available in several "flavours", either direct X.25 trunk connects over leased lines, through "PAD" interfaces, or by ordinary dialup modem access to X.25 "ports". To be useable in the context of mail transfers, you also have to use a file transfer protocol/mechanism of some sort on top of X.25. The most common being UUCP "f" protocol (through PADS or dialup), or "x" with direct X.25 connects. Whether you use X.25 or phones plus modems depends on a number of factors - usually the determining factor is cost. In North America, high speed modems (eg: 9600 baud and above) over telephone lines tends to be less expensive. However, Europe's really wierd phone system structure usually makes X.25 more cost-effective, and therefore, X.25 use in UNIX mail systems is much more common in Europe than North America. X.29 is the command set used to configure and establish X.25 connections when you're using asynchronous connections to a PAD. Networks: Internet: An "internet" is a network comprised of computers that talk to each other using TCP/IP, and usually SMTP for mail. The "Internet" is a vast network of hundreds of thousands of machines using SMTP protocol mail, communicating with each other over relatively high speed lines. But not all "internets" are connected to *the* Internet. The Internet grew out of a US government funded project in inter-computer communications that grew into an enormous network of systems. One of the principle characteristics of this network is that machines are addressed by domain names which identify the destination, rather than addresses that are constructed out of the route from machine-to-machine-to-machine. UUCP Network: The UUCP network is that set of machines that talk to each other via UUCP. Sending mail through this network requires that the sender know the network topology of UUCP links, and specify a path from one machine to the next. (There are, of course, ways around this. See the section on "do's and don'ts".) Mail addresses: Addresses: An email address is a method of specifying a given person on a specific machine. There are scads of conventions, usually determined by the presence of "@"'s, "!"'s and other special characters in the name. An address usually consists of two parts: a userid/name and a machine specification. A Domain address usually looks like: userid@domain-address Whereas a UUCP address usually looks like: siteA!siteB!siteC!userid Domain Addresses: Domains are a way of uniquely specifying a destination. Much like a postal address, a domain specifies a set of progressively more restrictive "domains" of the potential address space. It would perhaps be illustrative to give an example: clewis@ferret.marketing.fooinc.com You read these things right to left: "com" means the commercial domain. "fooinc" is the name of an organization within the commercial domain. "Marketing" is the name of a suborganization within fooinc, and ferret gives the name of a machine (usually). Domains can have any number of levels. The top level domain (com in the above example) has many possible values. In the United States, "com", "mil", "edu", and "gov" are fairly standard. Elsewhere, the top level domain tends to be a country code, the second level tends to be a province or state, OR a classification like "edu" or "ac" for academic (such as ac.jp, go.jp, ac.uk, edu.au, etc) and the third an organization. But, for example, there are many .com and .edu sites in Canada and other countries. FQDN A fully-qualified-domain-name (FQDN) has a entry for each level of the domain, from individual machine to top-level domain. In many cases, an organization has implemented an organizational "gateway" at a higher level of domain, so that people from outside don't have to specify FQDN's to get to a specific person. In the above example, for instance, "fooinc.com" may be sufficient to get to anyone inside fooinc, and "ferret.marketing" may not be necessary. On the other hand, people sometimes leave out the higher levels of the address, as in "ferret.marketing". This is a bad idea - because if the mail is cc'd out of the organization, chances are the external recipient cannot reply, because "ferret.marketing" is incomplete. So use addresses that are specified sufficiently for external users to use. (fooinc.com if a organizational gateway is used, the whole ferret.marketing.fooinc.com if not) NIC Internet TOP-LEVEL domains (edu, com, gov, mil) are controlled by a single organization, the NIC (internic.net). An organization "gets a piece" of the namespace by registering with the NIC, and then they are free to administer their own namespace (everything under fooinc.com) as they choose. The same is true for foreign countries; Once they have their top-level domain (usually the two-letter ISO country code) registered with the NIC, they do the rest, and divide it as they see fit. In contrast, on UUCPnet, all machine names everywhere share a single flat namespace. So it is important to choose a name that has not been used before. (See do's and don'ts). This is why FQDN's help. We can tell the difference between ferret.fooinc.com and ferret.blah.edu by their full names. (Instead of UUCP paths which may turn out to be wrong, and autorouting will probably send the mail to the wrong machine) MX record: A non-SMTP/Internet site that wishes to register on the Internet will need to get a "nearby" Internet site to set up a MX record for them. An MX record is essentially a domain-server database record that (effectively) registers your domain name on the Internet, and indicates that the Internet site knows how to forward mail to you. Usually via some non-SMTP/Internet route, such as UUCP. You can get an MX record for one site, or a "wildcard" MX record so that you can have your own subdomains. Bang-Paths: With UUCP mail, the MTA has to specify a route to get from one machine to another. "A!B!C!userid" means go to machine A, then B, then C, then user "userid" on C. You should strive, however, for a MUA that allows you to use domain addressing, and let the MTA figure out the bang routing as appropriate. Miscellaneous: Gateways: There are several meanings of this term, only three are relevant here. The first is a mechanism for getting from one network to another network that uses different protocols. The second is a mechanism for getting from one logical (often organizational) network to another using the same protocol. Often for example, there will be a LAN in one department of an organization, and one machine in the LAN has the connection to another LAN in another department. This means that mail from one LAN to the other has to pass thru the gateway machine. Another form, which we'll mention later is that of mail to news gatewaying. Routers: There are several definitions, but the most important is that part of the TA that figures out how to send a message to a given machine. This often uses a database that provides routes from one machine to the other machines on the network. Smarthost: In many cases, your machine won't know how to get to a specific destination. You can usually set up your mail system to send mail, that it doesn't know how to deliver, to a machine that is more likely to. RFC's: A set of documents that include formal descriptions of mail formats used on the Internet, and are adhered to by many non-Internet systems. More specifically, in the "worldnet" of Usenet, Internet and UUCP, the RFC's set the standards for mail exchange. RFC822, 1123 and 976 are the most important for Internet/UUCP mail. It should be pointed out, however, that there are some regions where the RFC's are not entirely respected. For example, the British academic email networks (JANET) uses domains, but they're specified backwards (they drive on the wrong side of the road too ;-). MIME: Mime is the official proposed standard format for multimedia Internet mail encapsulated inside standard Internet RFC 822 messages. Facilities include sending multiple objects in a single message, character sets other than US-Ascii, multi-font text messages, non-textual material such as images and audio fragments, and other extensions. For an | overview of Mime, see ftp.uu.net:networking/mail/metamail/MIME-overview.txt.Z. The defining document is Internet RFC 1341: N Borenstein & N Freed, ``Mime (Multipurpose Internet Mail Extensions) mechanisms for specifying and describing the format of Internet message bodies'' (June 1992). Also see RFC 1344: N Borenstein, ``Implications of Mime for Internet mail gateways'' (June 1992). RFC1341 and 1342 have since been superceded by RFC 1521 and 1522. Mime covers only message bodies, not message headers; to see how to represent non-Ascii characters in message headers, see Internet RFC 1342: K Moore, ``Representation of non-Ascii text in Internet message headers'' (June 1992). X.400: A CCITT standard for email formats, more or less an alternative to RFC 822/976/1123. This format will probably start taking over from RFC 822/976/1123 mail. It is likely to (already has?) become an ISO/IEEE standard along with OSI etc. "The Maps": A set of files describing machine-to-machine links distributed over Usenet in the group comp.mail.maps. These are usually posted on a monthly schedule, and can be automatically received and transformed into a routing database that describes the "optimal" route to each machine. These are operated by the "UUCP Mapping Project". See the README posted along with the maps for more details. Aliases: Aliases are a mechanism by which you can specify the destination for mail on your machine. Through the use of aliases you can redirect mail to "virtual userids". For example, you should have a mail destination on your machine called "postmaster", which is aliased to send the mail to the System Administrator (ie: you probably). Aliasing often also permits you to send mail to groups of users (not necessarily on the same machine as you) pipelines of commands or to specific files. Mailing lists: Are similar to Usenet newsgroups. They are usually aliases pointing to groups of users, and allow mail to be sent to the whole group at once. Mailing lists are set up to carry certain subjects. The difference between a mailing list and a Usenet newsgroup is that the messages are sent by mail, probably as a copy to each recipient, rather than broadcast. ------------------------------ Subject: Do's and Don'ts: 1) Register a domain name. Even on UUCP, where <machine>.UUCP is often used as a kludge, it is MUCH preferred that you obtain a real domain address. If you are directly connecting to the Internet, you will get one as part of your registration with the NIC. If you aren't connecting directly to the Internet, obtaining a registration will usually require you finding a nearby friendly Internet site willing to act as a mail forwarder to you from the Internet - the site that will set up a "MX record" for you. Many sites will do this for you for free, and several of the commercial email services (eg: uunet) will do it for you for a nominal charge (without requiring you buy the rest of their services). There are occasions where you can join what is called a "domain park". These are most often small regional groups of systems that have gotten one of their number properly registered as a domain, and provides forwarding services out to other systems. For example, in my address "ferret.ocunix.on.ca", "ocunix.on.ca" is a domain park made up of the Ottawa-Carleton UNIX User's Group, one of the other machines in the group provides a gateway between our systems and the Internet. 2) If your machine is going to "speak" UUCP to the outside world, choose a unique UUCP name. You can find out whether a name you want is taken by consulting the UUCP maps. Or by asking someone else who's using them. 3) Register your machine with the UUCP Mapping Project if you're going to use UUCP. Information on how to do this is included in the monthly maps postings in the file "README". This is usually only required when your machine talks UUCP to the outside world, or when other machines have to address you by your UUCP name. If you don't do this, somone else may choose the same name, and gross confusion will arise when smart routers won't be able to tell whether to send a piece of mail to you, or your doppelganger[s]. If you register with the UUCP Mapping Project, you have prior use, and people who choose the same name afterwards will be told to get a new one. If you're "behind" an organizational gateway, don't do this. (Your organizational gateway is the thing that needs to be registered) If you do fill in a map, please take the time to fill it in carefully, giving contact people and phone numbers. Just in case your machine goes crazy and starts doing something nasty. Note expecially the latitude and longitude. Get it right, or omit it. Brian Reid gets really annoyed with sites that are half a world away from where they really are. 4) If you're going to be setting up multiple machines, have only one or two connections to the outside world. 5) Install a mail system that understands domain addressing, even if you aren't registered. (In fact, all of the suggested configurations in this FAQ do) 6) *Never* use UUCP bang-routing with the MUA if you can possibly avoid it - each of the suggested mail configurations provide mechanisms where you, the user, do not have to specify routes to the MUA - you can specify domains, and the TA will do the routing (possibly bang-routing) for you. Important: many mailers that understand UUCP attempt to be pedantically "UUCPish" in the construction of headers, such as generating "bang routes" in From:/To: etc. lines. Which, given that the whole "mail network" is generally converging on more Internet-like standards, and that even UUCP sites are using fully domain-capable mailers, is a big mistake. RFC976 attempts to codify a "meta standard" that allows the coexistance of RFC822/1036 (Internet mail) with UUCP-based networks. What this means is, essentially, that headers are formed in the SMTP form, even if the transport will be via UUCP. Unfortunately, however, many mailers insist on "UUCP-izing" perfectly useable Internet/domain headers. "Fixing" them to prevent this is sometimes difficult. Sendmail is almost always a problem in this regard. 7) Find a friendly neighboring SA to help. A SA who has already operating mail in your area will help smooth over the regional "gotchas" that are bound to crop-up. And advise you on the right software to use, where to obtain it, and how to install it. 8) Do NOT use "any old" Map unpacking program. Most available map unpacking programs automatically run the shell (or shar) to unpack map articles. Since it is trivially easy to forge map articles, using this type of unpacking program can easily let very destructive trojan horse or virus programs into your machine. The two specific map unpackers described in this FAQ are known to be secure from such attacks. Do not run any other unpacker unless you are aware of the issues and can inspect the code for such vulnerabilities. [If you know of other "secure" map unpackers that are generally available, please let me know] 9) If the people on your site, or small network, receive mailing lists, it's often a good idea to gateway them to news: Netnews often performs many of the same services as email. The primary difference is that messages are centrally stored, rather than delivered to individual's mailboxes, and that distribution looks more like a broadcast then a set of point-to-point communications. This means usually means that news can handle more volume, more efficiently, then email can. Because of the differences (and also the similarities) people often want to tie news and mail together. This is known as "gatewaying." For example, a small software development site might subscribe to the X Windows mailing list. Rather than have (say) eight copies of each mail message sent to their host, they would rather have it stored as a local newsgroup that everyone in the company can read, and which can be centrally archived. This is a typical use of a "mail to news" gateway. When a user makes a posting to this local group the article should be sent back out to the mailing list; this is a typical use of a "news to mail" gateway. On a larger scale, the "inet" groups are bi-directional gateways of Internet mailing lists. Within mainstream Usenet, many popular groups such as comp.windows.x, comp.protocols.tcp-ip, comp.unix.wizards, and so on, are gatewayed to mailing lists and back. Many subtle issues often come up when gatewaying mail and news, so unless you are experienced you should use one of the already-available packages for your local organization. For example, you probably do not want to write a brand-new Perl script and create a new "inet" newsgroup. The C News distribution includes some basic gateway tools in the contrib/nntpmail directory. Many people use Rich $alz's "newsgate" package that appeared in comp.sources.unix Volume 24; it includes discussion of some of the more subtle issues that come up. Before starting a mailing list gateway, apart from the technical aspect of the job you should also be aware of one important point: mailing-lists are considered private, whereas newsgroups are public. One can know who gets a list, but not who reads the group. It is always wise to get the authorization of the mailing-list manager and of the readers before creating a mail/news gateway. 10) If you're connecting to the Internet, or are setting up a large local internet, you really should get a copy of the DNS and BIND book mentioned in the bibliography. -- Chris Lewis: _Una confibula non sat est_ Phone: Canada 613 832-0541 Latest psroff: FTP://ftp.uunet.ca/distrib/chris_lewis/psroff3.0pl17/* Latest hp2pbm: FTP://ftp.uunet.ca/distrib/chris_lewis/hp2pbm/* Archive-name: mail/setup/unix/part2 Last-modified: Thu Jan 26 01:28:55 EST 1995 UNIX EMail Software - a Survey Chris Lewis clewis@ferret.ocunix.on.ca [and a host of others - thanks] Copyright 1991, 1992, 1993, Chris Lewis Redistribution for profit or altered content/format prohibited without permission of the author. Other redistribution must contain this copyright notice and attribution. ------------------------------ Subject: Configuration Issues: What you need for email connectivity is determined by: 1 What networks you intend to connect to. The Internet (hence SMTP)? UUCP sites? X.400? Bitnet? Others? Combinations? 2 What links you have or are willing to install Internet T1? T2? UUCP? Other? [Details on how to make your connections is beyond the scope of this FAQ, but can usually be found out from the provider (other end) of the link] 3 what user interface you want to use. This is largely an independent issue, so consult the Specific Package Reviews directly. ------------------------------ Subject: Recommended MTA Configurations: These configurations are based upon my own experience, and the experience of others. Careful installation of any of these configurations will result in a solid, reliable mail system that respects the appropriate "do's and don'ts". Each configuration represents a compromise of ease of installation and maintenance versus sophistication and capabilities. One thing you should consider is what you already have on your system. You will invariably have "binmail", and will have a good chance at already having sendmail. Some systems come with smail (if 2.3, junk it) The configurations shown below are *minimal* configurations, so you should consider whether you want to use what you already have or not. Scenario 1: Only UUCP connections. Smail 2.5. If you want to set up a routing database of your own, you will also need pathalias, and unpackmaps or uuhosts. Instead, though, you can configure smail 2.5 to smart-host most destinations to a nearby friendly site who'll do your routing for you without having to run the routing software. Note further, that you can run pathalias on just a subset of the full set of maps. [Unpackmaps makes this particularly easy to do] Smail 2.5, as shipped, does not support mail-to-pipeline or mail-to-file aliasing. If you need these, at a minimum, you should obtain lmail. If you intend more than casual use of these features, it is recommended that you obtain deliver or procmail instead of lmail. Even if you have sendmail already, you can integrate smail 2.5 with it to do your UUCP routing. (though, some later versions of sendmail can do routing themselves) If you're a little more demanding of your mail connections, smail 3 is also a good choice, and works particularly well for systems that are UUCP connected to Internet sites. Scenario 2: SMTP connections (optionally, some UUCP connections too). Generally speaking, sendmail will do this for you and you have a good chance to have it already. However, for the novice, it is recommended that smail 3 be used instead [see review of sendmail below]. Smail 3 includes all of the routing software and can do mail-to-pipeline and mail-to-file, so none of the auxiliary programs mentioned in scenario 1 are necessary. Most sendmails don't include UUCP routing mechanisms, so you would need pathalias and unpackmaps or uuhosts if you wish to set up a UUCP routing database. Further, most sendmails don't know how to query a pathalias database directly, so you may have to hack your own path lookup program into the sendmail.cf (smail 2.5 can be used for this purpose provided that you will have a UUCP link to the outside world) Both MMDF and PP can also be used, but PP is usually overkill. Deliver or procmail are still quite useful in this configuration for extended alias facilities. Scenario 3: Connections to other networks (optionally including SMTP or UUCP), or very high loading. Your best bets are MMDF, PP or zmailer. You can implement other network interfaces with sendmail, but not only will you probably have to roll your own, but sendmail can't cope with high loading very well. Ditto smail 3. There are other configurations. See the Package Reviews to determine which packages are appropriate. ------------------------------ Subject: Package Reviews Honesty requires me to point out which software packages were reviewed by their author (including me ;-). I do so by appending a "*" to the name of the author. In some cases, the material has been cribbed from FAQ's or general information blurbs. It is worth noting, though, that most of these packages are well known, and have been in operation at many sites for periods of a year or more. These packages do their job well, and have been extensively thrashed out in the best debugging laboratory in the universe (Usenet ;-) A few packages have been mentioned prior to their release. (unpackmaps 4, the occasional beta version). It is recommended that these versions be avoided by novices until they have had a chance to settle for a little while. This FAQ will note when such software seems (according to rumour *I* hear) to be stable enough for general use. Some of these packages are capable, by various bits of hackery, of doing a lot more than is claimed for them. But I refrain on telling you how to "take the covers off". Given the intended audience, that would be tantamount to trying to teach preschoolers do-it-yourself brain surgery. Please don't take this as condescending - I've been working on/in/with email systems for over 12 years and I *still* won't play with (as just one example) sendmail.cf's. Therefore, I restrict myself largely to "out-of-the-box" functionality, "fill-in-the-blank" configurability, and normal documented installation procedures. Beyond that, you're on your own. binmail binmail is usually really called "mail". On System V prior to Release 4, it is a really simple UA that does dual duty as the TA. It's pretty awful because it doesn't know how to set up headers properly, doesn't even know what a "Subject:" line is, and there's no way to do any kind of aliases. On BSD, binmail invokes sendmail to do the MTA function. On System V prior to Release 4, you really do want to replace binmail's MTA functionality with something else. However, you should not replace it in its "mail" (UA) functionality, because many system-level administration mechanisms will break. Any new UA should be installed as a different name than "mail". Beginning with System V Release 4, "binmail"'s transfer agent capabilities were considerably enhanced to have similar capabilities to Smail 3 and sendmail. There is usually no need to replace it with another mail agent. (See SVR4 mail discussion below) Binmail stores mail in "mbox" format. rmail binmail's TA functionality is implemented by linking mail to rmail. It's rmail that you'd want to replace with smail 2.5 etc. Mail The original BSD UA. It can support local profiles, aliases, folders, header previewing, out-going mail recording and all sorts of good stuff. An "okay" UA. Available from BSD "freed-sources" archives. Mail stores mail in "mbox" format. mailx AT&T's answer to BSD "Mail", from which it is descended. Some versions, such as the 3b1 one, should be avoided because of a buggy port. Not available in source form (it's proprietary but ubiquitous enough to be mentioned here). Mailx stores mail in "mbox" format. mush: author Dan Heller* <argv@well.com> The "Mail User's Shell" is a "shell" for mail users. That is, it has its own environment where you can configure not only the user interface, but the actual internal mechanisms. Internally, mush has a csh-like scripting language, altho it's not as powerful as csh. It has command-line aliases, file completion, if-else state- ments, command piping, and so on. Because you can build your own commands, you can virtually build your own library of email features. Mush has two tty-based interfaces: the standard tty-mode (ala BSD Mail or sys-v mailx) and the fullscreen/curses mode (ala vi, emacs or even Elm). You can set up key bindings that execute one or more mush commands, personalized commands or even UNIX commands. You can even emulate keyboard input with keyboard macros and mappings. Mush also has a SunView interface that is more powerful than Sun's Mailtool, yet backwards compatible with most versions. Most sunview users (if there are any left these days) prefer MushView over Mailtool. The current version of Mush is 7.2.3, last posted in comp.sources.misc volume 18 (with subsequent patches). All three interfaces are available in one runtime binary. Except for the MushView interface (which is only available on for suns), Mush is portable to everything that runs UNIX. There is also a DOS port available for PCs and can run on most 286 machines. An older version of Mush (6.5) can run on as little as 640 of RAM. (Mush-PC is typically used with UUPC.) The "next generation" of Mush is a commercial product called Z-Mail from Z-Code Software (mail info@z-code.com for details). All aspects of Mush are retained, yet it has grown to be far more powerful. It runs under X windows with either a Motif or Open Look interface and also supports multi-media, user "functions" and a suite of new features. Mush stores its messages in "mbox" format, or MMDF format if you're using MMDF as your MTA. The newsgroup comp.mail.mush is dedicated to it. [Note: Z-Mail is not related at all to Zmailer. Zmailer is a MTA] elm: coordinator Syd Weinstein* <syd@DSI.COM> (cribbed from comp.mail.elm FAQ) Elm is designed to run with "sendmail" or "/bin/rmail" (according to what's on your system) and is a full replacement of programs like "/bin/mail" and "mailx". The system is more than just a single program, however, and includes programs like "frm" to list a 'table of contents' of your mail, "printmail" to quickly paginate mail files (to allow 'clean' printouts), and "autoreply", a systemwide daemon that can autoanswer mail for people while they're on vacation without having multiple copies spawned on the system. The most significant difference between Elm and most other mail systems is that Elm is screen-oriented. Upon further use, however, users will find that Elm is also quite a bit easier to use, and quite a bit more "intelligent" about sending mail and so on. Current release is Elm 2.4 PL24.. Information on access is available from the server at DSI.COM: send mail to archive-server@DSI.COM send elm index [Ed: elm is particularly good for novices. The only drawback that I've heard is that elm is a bit less user configurable than, say, mush] MM: Contact Joseph Brennan* <info-mm@cunixf.cc.columbia.edu> Columbia University in the City of New York (cribbed from MM man page.) mm is a powerful electronic mail system which allows you to send, read, edit and manage messages quickly and easily. It is designed to have the same interface as the MM program written and developed for DEC20s over a period of many years. mm was written using the CCMD package developed at Columbia. Thus, it has copious internal help, completion of partially typed commands on use of the TAB key, and help on partial commands when ? is typed. mm can read several mail-file formats. Its default is mbox, the same format used by unix mail. It also can read babyl, used by emacs rmail, and mtxt and MH. It can copy messages from one file type to another. MM is a Freeware MUA copyright by Columbia University (as is this description). MM is available by anonymous ftp from cunixf.cc.columbia.edu, directory mm. The file mm-intro.txt there is a longer description of how it was developed. [Ed: MM also appears to be a good UA for novices. From the examples in the manual page, it handholds extensively and is not screen oriented.] MH: Maintainer John Romine <Bug-MH@ics.uci.edu> The big difference between MH and most other "mail user agents" is that you can use MH from a UNIX shell prompt. In MH, each command is a separate program, and the shell is used as an interpreter. So, all the power of UNIX shells (pipes, redirection, history, aliases, and so on) works with MH--you don't have to learn a new interface. other mail agents have their own command interpreter for their individual mail commands (although the mush mail agent simulates a UNIX shell). Mail messages are stored in individual files. The current version of MH is 6.8.3 and supports MIME. MH comes standard with Ultrix 4.0 and later, and AIX 3.1 and later. via anonymous ftp: ftp.ics.uci.edu [128.195.1.1] pub/mh/mh-6.8.tar.Z 1.6MB louie.udel.edu [128.175.1.3] portal/mh-6.8.tar.Z 1.6MB comp.mail.mh discusses MH, and contains a FAQ article. Jerry Peek wrote a book about MH called "MH & xmh: E-mail for Users & Programmers", ISBN 1-56592-027-9, published by O'Reilly and Associates, second edition, September 1992. XMH: <extracted from the manual page> The xmh program provides a graphical user interface to the MH Message Handling System. To actually do things with your mail, it makes calls to the MH package. Electronic mail messages may be composed, sent, received, replied to, for- warded, sorted, and stored in folders. xmh provides exten- sive mechanism for customization of the user interface. xmh is part of the standard X distribution from the X Consortium. EXMH: Author Brent Welch* <welch@parc.xerox.com> | exmh is an X interface to the MH mail system. It is written in John | Ousterhout's Tcl/Tk language system and requires that you have both | Tcl/Tk and MH installed. If you have metamail installed, exmh | supports MIME. As well as providing the usual layer on top of MH commands, exmh has a number of other features: MIME support! Displays richtext and enriched directly. Parses multipart messages. Displays hot buttons that invoke external viewers (metamail) for things not directly supported. Built-in editor allows simple composition of text/enriched format. Color feedback in the scan listing so you can easily identify unseen messages (blue), the current message (red), deleted messages (gray background), and moved messages (yellow background). Xresources control these color choices. A folder display with one label per folder. Color highlights indicate the current folder (red), folders with unseen messages in them (blue), and the target folder for moves (yellow background). Nested folders are highlighted by a shadow box. A cache of recently visted folder buttons is also maintained. Monochrome highlights are reverse video for the current folder, bold box for folders with unseen messages, and stippled box for the target of move operations. Clever scan caching. MH users know that scan is slow, so exmh tries hard to cache the current state of the folder to avoid scanning. Moves and deletes within exmh do not invalidate the cache, and background incs that add new messages are handled by merging them into the scan listing. The scan cache is compatible with xmh. Numerous other features, such as "facesaver" display, backgrounds, dialog-box interface to MH "pick", folder searching and listing, designed for inclusion of user "hooks" and interfaces etc. | Ftp'able from harbor.ecn.purdue.edu:/pub/tcl/code/exmh-1.3beta.tar.gz GNU Emacs Rmail: Rmail is an Emacs subsystem for reading and disposing of mail. Rmail stores mail messages in Rmail files in BABYL format (originally used under the ITS operating system), although it can incorporate new mail from MMDF and Unix format files, or mixed-format files. Reading the messages in an Rmail file is done in a special major mode, Rmail mode, which redefines most letters to run commands for managing mail. Rmail can do the standard things such as displaying, deleting, filing, or replying to messages. Replying uses another Emacs subsystem, Mail mode. Messages can be saved in either BABYL or Unix format. Rmail maintains per-message attributes and user-defined labels. Rmail can burst message digests. VM: Author Kyle Jones* <kyle@uunet.uu.net> VM (View Mail) is a GNU Emacs subsystem that allows UNIX mail to be read and disposed of within Emacs. Commands exist to do the normal things expected of a mail user agent, such as generating replies, saving messages to folders, deleting messages and so on. There are other more advanced commands that do tasks like bursting and creating digests, message forwarding, and organizing message presentation according to various criteria. The current version of VM is VM 4.41. FTPable from: | ftp.uu.net networking/mail/vm-5.72beta.tar.gz archive.cis.ohio-state.edu pub/gnu/emacs/elisp-archive/packages/vm-4.41.tar.Z VM is discussed in gnu.emacs.vm.info, or by mailing list by sending an e-mail request to info-vm-request@uunet.uu.net. MH-E: Maintainer: Stephen Gildea <gildea@bbn.com> MH-E is an interface to MH from within GNU Emacs. It helps if MH was compiled with the MHE compiler flag. MH-E is distributed with both GNU Emacs and MH. Choose the later version. C-Client: Author Mark Crispin <mrc@panda.com> Software writers only: C-client is a general library useful for creating MUA's. It provides a high level logical interface for retrieving and manipulating mail messages. It supports the latest draft of MIME (proposed Internet standard for multipart, multimedia, typed electronic mail). It is driver based, and easily ported to new platforms and MTA's, already supports BSD, SysV, DOS, Macintosh and TOPS-20(!), and supports present mail and mailbox formats. Just the thing if you want to write a new MUA. Contact the author for more details. Metamail: Author N. Borenstein [Described by Paul Eggert, eggert@bi.twinsun.com] Metamail is a software implementation of Mime, designed for easy integration with traditional mail-reading interfaces -- typically, users do not invoke metamail directly. Ideally, extending the local email or news system to handle a new media format is a simple matter of adding a line to a mailcap file. Mailcap files are described in RFC 1343: N Borenstein, ``A user agent configuration mechanism for multimedia mail format information'' (June 1992). The source code for metamail can be found in ftp.uu.net:mail/metamail/mm.tar.Z. To join its mailing list, write info-metamail-request@thumper.bellcore.com. MailManager: Author Mark Crispin <mrc@panda.com> A MUA implemented using C-Client for NeXT computers. Pine: Authors Lundblade, Seibel, and Crispin <pine@cac.washington.edu> Pine is a mailer developed by the University of Washington Office of Computing and Communications. It has been designed for ease-of-use and with the novice computer user in mind. It is based on Internet mail protocols (e.g. RFC-822, SMTP, IMAP, and MIME) and currently runs on a variety of UNIX platforms, and a version is apparently available for MSDOS. The guiding principles for achieving ease-of-use in Pine were: careful limitation of features, one-character mnemonic commands, always-present command menus, immediate user feedback, and high tolerance for user mistakes. It is intended that Pine can be learned by exploration rather than reading manuals. A stand-alone version of Pico, Pine's message composition editor, is also included. It is a very simple and easy to use text editor with text justification and a spelling checker. Features: - Mail index showing a message summary which includes the status, sender, size, date and subject of messages. - View and process mail with the following commands: forward, reply, save, export, print, delete, capture address and search. - Address book for saving long complex addresses and personal distribution lists under a nickname. - Multiple folders and folder management screen for filing messages. - Message composer with easy-to-use editor and spelling checker. The message composer also assists entering and formatting addresses and provides direct access to the address book. - Online help specific to each screen and context. - Supports access to remote mail repositories via the IMAP2 protocol defined in RFC-1176. - Soon to support multi-part mail conforming to proposed MIME Internet standard, allowing sending of sounds, graphics such as GIF and TIFF files, and binary files such as spreadsheets. Pine, including source code, is freely available via anonymous FTP from ftp.cac.washington.edu on the Internet. Other provisions for distribution have not been made. From the Internet, you may try out Pine and leave comments by telneting to "demo.cac.washington.edu" and logging in as "pinedemo". To join the Pine mailing list for announcements send a | email request to "majordomo@cac.washington.edu" with body | "subscribe pine-info". Pine is very portable and runs on a variety of UNIX machines including DECstations, NeXTs, VAX's and Suns. Pine was originally based on Elm, but it has evolved much since, ("Pine Is No-longer Elm"). For further information send e-mail to pine@cac.washington.edu. Pine is the work of Mike Siebel, Mark Crispin, and Laurence Lundblade at the University of Washington. Ream: Author: Paul Dourish* <dourish@europarc.xerox.com> Ream is a curses-based mail user agent for a variety of UNIX flavours; at one time or another, it's run on everything from a PC running Linux to a Cray Y/MP running UNICOS. It was originally written at the University of Edinburgh, and has spread not least through the subsequent geographical distribution of alumni. It remains minimally supported by its author (Paul Dourish <dourish@europarc.xerox.com>). Ream is similar to elm in a number of ways, but considerably smaller and with a stronger separation between MUA and MTA behaviours. It runs over sendmail, mmdf and PP. It is available by anonymous ftp from parcftp.xerox.com, in pub/europarc/reamXXX.tar.Z, where XXX is a slowly incrementing version number. XLView: Author: Several. Mike Macgirvin* <mtm@camis.stanford.edu> Current version 1.1 (Developer Release). XLView (previously known as "Ximap") is an X based mail reader using the IMAP (IMAP2bis) protocol, for managing complex mail tasks. It utilizes the X window system to allow independant processing of multiple mailboxes (even on multiple servers) simultaneously. Each "read" and "compose" process is handled in an independant window as well. It handles many complex MIME messages with the help of external multi-media handlers based partially on "metamail", and include facilities for file attachments of several common types. It includes an address book with insert completion abilities and for maintaining addresses. Of course it has the normal move/copy/save/reply/forward/print etc., functions one would expect and text may be cut and pasted from other open X sessions. The most powerful feature of the latest release is the "Logical Viewer" which allows one to create rule based sorting of their mailbox based on addresses, dates, contents, message flags and other criteria. Each existing message (and each new message) is evaluated and stored in the appropriate logical view, which may be opened as if it were a separate mailbox (but all the while it only represents a different ``view'' of your system mailbox). Each mailbox or saved folder may have independant rulesets. Status changes also are evaluated as they occur and the rules applied accordingly. The rule language is powerful, yet easy to grasp; i.e. FROM clyde@podunk.edu OR jim SINCE YESTERDAY AND UNSEEN Currently tested with SunOS4.1.x and Ultrix running X11R5. | Several alternate system ports including SVR4 are available. | FTP: camis.stanford.edu/pub/xlview-2.0.tar.Z Information: xlview@CAMIS.Stanford.EDU Principal Authors: Kevin Brock, Bill Yeager and Mike Macgirvin at the Center for advanced Medical Informatics at Stanford. | Z-Mail: Z-code Software Corp, Barbara Tallent* <tallent@ncd.com> Z-Mail, a UNIX World Magazine "Product of the Year" winner for | 1991, is a complete electronic mail system for workstations, PCs, | ASCII terminals and Macs. Z-Mail provides Motif and Open Look graphical user interfaces, as well as two character modes. The software has been ported to nearly every system that runs UNIX, and it works with all standard UNIX mail transport agents including sendmail, binmail, smail, MMDF and X.400 gateways. Z-Mail can replace or coexist with standard mail user agents on the system, including BSD Mail, AT&T mailx, Sun Mail Tool, Elm or Mush. Most anyone can use Z-Mail "off the shelf" and immediately benefit from its simple interface and advanced features. | The 'fullscreen' character mode has become its own product, Z-Mail Lite. | It's available immediately. Z-Mail also includes Z-Script, a powerful scripting language that enables users to customize and extend Z-Mail's capabilities. Z-Mail's multi-media capabilities allow easy integration with best-of-class products including spreadsheets, desk-top publishing, graphics, fax, voice, and video. For example, when users receive a spreadsheet file, Z-Mail can be configured to automatically launch the associated application and load the the attachment automatically and transparently to the user. Z-Mail understands MIME-format documents and is also compatible with Sun's multimedia Mailtool. For more information on Z-Mail, contact: | Z-Code Software Division | Network Computing Devices, Inc. | 101 Rowland Way, Suite 300 | Novato, CA 94945 | tel: (415) 898-8649 | fax: (415) 898-8299 | E-mail: info@z-code.com | URL: http://www.ncd.com/ | You can obtain a demo copy of Z-Mail from ftp.z-code.ncd.com in the | directory pub/z-code/zmail/3.2 for assorted UNIX versions. The file | is named zm32.XXX.tar.Z where XXX is your type of machine. Windows | and Macintosh versions are also available for FTP in the directories | pub/z-code/zmail/zm-win and pub/z-code/zmail/zm-mac. | | URLs: | | ftp://ftp.z-code.ncd.com/pub/z-code/zmail/3.2/ | ftp://ftp.z-code.ncd.com/pub/z-code/zmail/zm-mac/ | ftp://ftp.z-code.ncd.com/pub/z-code/zmail/zm-win/win321/ | | Contact <keys@z-code.com> for an activation key after downloading your | demo copy. [As mentioned previously, Z-Mail is the commercial variant of mush. Ed] -- Chris Lewis: _Una confibula non sat est_ Phone: Canada 613 832-0541 Latest psroff: FTP://ftp.uunet.ca/distrib/chris_lewis/psroff3.0pl17/* Latest hp2pbm: FTP://ftp.uunet.ca/distrib/chris_lewis/hp2pbm/* Archive-name: mail/setup/unix/part3 Last-modified: Thu Jan 26 01:29:12 EST 1995 UNIX EMail Software - a Survey Chris Lewis clewis@ferret.ocunix.on.ca [and a host of others - thanks] Copyright 1991, 1992, 1993, Chris Lewis Redistribution for profit or altered content/format prohibited without permission of the author. Other redistribution must contain this copyright notice and attribution. uumail: Uumail is a very old and obsolete precursor to smail 2.5. Included here only because I know that uumail sites still exist. You should not install uumail in new configurations, and existing uumail sites should convert to something more modern. smail 2.5: author The UUCP Mapping Project Smail 2.5 is a small, simple and hard-coded rule MTA for use on UUCP networks. It understands RFC compliant headers, will generate RFC compliant Internet-style headers, can use domains, aliases, a pathalias UUCP routing database, and is very simple to install. For full functionality, you will also want pathalias and a map unpacker. The one thing it cannot do by itself is mail-to-pipe and mail-to-file aliasing. For that, you need Zeeff's lmail, deliver or procmail. Smail 2.5 has the capability of coalescing addresses into single UUCP transfers, and knows how to query UUCP for the names of UUCP neighbors, and autoroute if necessary. Smail 2.5 has a few bugs that are (usually) pretty rarely seen in operation. There have been a number of patches posted for it, but it is recommended that you do not apply them - some were ill-conceived, buggy in their own right, or conflicting with others. The only patches that I feel safe in recommending is Chip Salzenberg's patches for use with Xenix MICNET - which are unnecessary unless you are in the unfortunate position of having to actually *use* MICNET. Chip Salzenberg's "deliver" package (see below) combined with "smail-deliver.pch" from comp.sources.unix, volume 25 issue 107, makes the MICNET modifications to smail itself unnecessary. In particular, do not apply the "mail-to-pipe/file" patches that float around for smail 2.5. These are a major security hole. Smail 2.5 can also be used with sendmail as a UUCP router. Smail 2.5 was posted in comp.sources.unix in 1987, volume 11 with archive name "smail3" (but it isn't the same thing as smail 3 below). lmail: Author Jon Zeeff <zeeff@b-tech.ann-arbor.mi.us, zeeff@ais.org> When you install smail 2.5, you link the original /bin/mail (binmail above) to /bin/lmail to perform the task of actually delivering the mail to the user's mailbox (LDA). Since smail 2.5 was not capable of doing mail-to-pipe and mail-to-file aliasing, Jon Zeeff wrote a replacement lmail that implemented these (along with user mailbox delivery). Jon's program is okay for casual use, but has some pretty serious bugs. Fixed versions are available, but you're probably better off installing deliver or procmail. smail 3: Author Ronald S. Karr* <tron@veritas.com> and Landon Curt Noll. Smail3.1 is a domain-capable mail router and delivery program that works in the UUCP zone and on the Internet and that is capable of gatewaying between the two. It was written primarily by me (Ronald S. Karr) and Landon Curt Noll, with the blessings of the original Smail1 and Smail2 authors. Smail3 supports SMTP, UUCP mail, alias files, .forward files, mailing list directories, pathalias files, /etc/hosts files, the domain name system, and can also query uucp for neighboring sites, automatically. It also supports use of encapsulated SMTP commands for delivery over UUCP connections, which allows batching of multiple messages into a single UUCP transaction, and allows many addresses to be passed with a single message transfer, which can greatly decrease the traffic generated for large mailing lists. It is also very simple to configure with a reasonable certainty of correctness. Smail3 includes pathalias and a reliable map unpacker. Rather than using configuration files to resolve addresses based on their syntax, ala sendmail, Smail3 uses a database metaphore for resolving addresses based on their contents. The set of methods that Smail3 uses for resolving local addresses and hosts is configurable and extensible. Smail3's methods for parsing addresses are not configurable. It is the opinion of the authors that addressing on the Internet and in the UUCP zone has become sufficiently standardized that attempts to allow configurability in this area are now a hindrance to the correct working of the network. Questions related to Smail3 are usually discussed in comp.mail.misc. There are also two discussion mailing lists. To join the mailing lists, send mail to: smail3-users-request@cs.athabascau.ca The current release of Smail3 can be found on uunet, in the file /archive/networking/mail/smail/smail-3.1.29.1.tar.Z. New versions are released on a haphazard basis. Official releases are always made available in the /archive/networking/mail/smail directory on uunet. Smail 3 is covered under the GPL (if it matters) sendmail: Original author Eric Allman Sendmail is the granddaddy of all intelligent MTA's. It can do just about anything. It's main problem is that it can do just about anything. Modification of sendmail's configuration tables (which is necessary with most vendor-supplied versions) is NOT for novices. The language of the sendmail.cf is cryptic, but that isn't really the problem (and this problem can be solved by using "EASE", a sendmail.cf writing language, or the UIUC IDA kit's configuration file building tools). The problem is that it's extremely difficult to know when the rules you are implementing are the right thing-- many sendmail configurations do slightly buggy, or even extremely buggy, or illegal things. The default configurations generated by the UIUC IDA kit are, however, very good at Doing the Right Thing under most, if not all, circumstances. I hear similar things about the Sendmail 8.6 package. Worse, every vendor's version of sendmail is different, and many of their sendmail.cf's don't work at all. HPUX is one example of where the sendmail.cf is actually pretty sane. HP is to be congratulated. On the other hand, some vendors, who shall remain nameless, can't even get their sendmail to deliver to local users, let alone get their sendmail to speak SMTP on a LAN. The major problem with sendmail is that it tries to do too many things. Rather than confining itself to handling local mail, and simply routing external mail and leaving transport-specific format/standards conversions to transport software, it attempts (nay virually *insists*) that you have to do all of the format/standards conversions for different transports all at once. Which results in configuration files that are veritable nightmares to maintain. And that many sendmail.cf files depend on out-of-date standards for different transports, rather than trying to unify them (as in RFC976). Indeed, while common wisdom and practice mandates that MTAs don't rewrite headers, sendmail makes it extremely difficult to *not* rewrite headers. Which results in many major systems attempting to "be nice", yet, totally scramble return addresses and the like. There are several different sendmail lineages in the world but they seem to be coming together now with Eric Allman's work creating sendmail V8.x. Sendmail V8.1 was shipped with BSD 4.4 UNIX. V8.2 and above (available from ftp.cs.berkeley.edu) is the latest. V8.6.9 is now current. Another solid "modern" version is UIUC IDA version 5.65c (5.65d in alpha test), from ftp.uu.net or uxc.cso.uiuc.edu. This version has been pretty stable since 1991. Paul Pomes, <Paul-Pomes@uiuc.edu>, is controlling the IDA Sendmail releases. If you want to use sendmail, it is strongly recommended that you obtain the UIUC IDA or sendmail 8.6+ versions. They are much more likely to do the right things with mail coming from, or ultimately going to, UUCP sites and is much easier to maintain. IDA sendmail can handle pathalias-style UUCP routing quite well. Another point to remember is that sendmail, historically, has been where a large number of severe security holes have been found. From the infamous RTM Internet Worm, to the two latest ones "CERT"d in the past 6 months. Indeed, if your application is security-critical, you should *not* use sendmail on your security-critical systems, such as your firewalls. Theoretically, all of these problems have been removed from sendmail 8.6.5 or later, but, there's bound to be more found. While some of this can be due to the much larger installed base of sendmail, other mailers with improved function partitioning (such as the channel-oriented MMDF or PP) will usually be inherently more secure. I am being harsh on sendmail - sendmail programming is, after all, a good source of revenue for consultants ;-) But, if you obtain a good configuration (like the aforementioned HPUX version), or are willing to spend the time to learn it, sendmail will do what you want. Well. IDA or 8.x sendmail is STRONGLY recommended. Don't, however, even think of playing with the configuration files without a copy of the Sendmail book by Costales, Allman and Rickert mentioned in the book list above. It is *absolutely* essential. Sendmail is discussed in comp.mail.sendmail. EASE version 3.5 was posted in volume 25 of comp.sources.unix and is available from wuarchive.wustl.edu [128.252.135.4] (directory /usenet/comp.sources.unix/volume25/ease) and many other c.s.u archives. | ZMailer: Original author Rayan Zachariassen* <rayan@cs.toronto.edu> | Current author Matti Aarnio <mea@nic.funet.fi> ZMailer is intended for gateways or mail servers or other large site environments that have extreme demands on the abilities of the mailer. Code and Design features: + Strong limits on host impact. + Secure design (and hopefully implementation). + Natural fit for client/server environments. + Extremely customizable configuration mechanism. + Flexible database interface with support for: sorted files, unsorted files, dbm, ndbm, gdbm, nis (yellow pages), dns (BIND resolver), /etc/hosts file, and in-core data. + Efficient message queue management. + Fast binary-transparent SMTP server and client. | + MIME-facilities for message transport. | + Low-technology implementation, with high-tech options for performance. Default configuration file features: + Default configuration will work for most sites. + Network protocol support for: smtp, uucp, bitnet, mail to news. + An easy way of overriding any external routing information. + Automatic handling of mailing lists. | It is available by anonymous FTP from: | ftp://ftp.funet.fi/pub/unix/mail/zmailer/ (Mr. Aarnio's versions) | Alternate (some of them old) versions: | ftp://ftp.cs.toronto.edu/pub/edwin/zmailer2.2.e4.tar.Z | ftp://ftp.cs.toronto.edu/pub/zmailer.tar.Z MMDF: [reviewed by I.Sparry@gdt.bath.ac.uk] MMDF is a MTA. It works on the principle that you have communications channels, both incoming and outgoing, and it arranges for messages to pass between them. Strong points include: * Ability to turn up and down debugging level on the fly * Very strong on authentication, and permission checking. * Can block mail based on who it came from, how it got there, who it is going to. It is older than sendmail, simpler than sendmail, and it is a great pity that it was not shipped as standard instead of sendmail. [MMDF is standard on some systems - primarily SCO UNIX.] It has one major advantage to people in the UK, in that it knows how to handle mail addresses in our 'correct' format (Most significant part first, e.g. net.uu.uunet), as well as the thing the rest of the world uses :-) :-) A mailing list for MMDF discussion is at mmdf2@a.cs.okstate.edu requests for addition to the list to mmdf2-request@a.cs.okstate.edu. The most recent release of MMDF is available for anonymous FTP from a.cs.okstate.edu:/pub/mmdf-2.43.tar.Z. PP: Author University College London PP is a Message Transfer Agent, intended for high volume message switching, protocol conversion, and format conversion. It is targeted for use in an operational environment, but may also be useful for investigating Message related applications. Good management features are a major aspect of this system. PP supports the 1984 and 1988 versions of the CCITT X.400 / ISO 10021 services and protocols. Many existing RFC 822 based protocols are supported, along with RFC 1148 conversion to X.400. PP is an appropriate replacement for MMDF or Sendmail, and also supports SMTP and UUCP mail. For more information contact: support@xtel.co.uk or xtel@cs.nott.ac.uk The latest version is PP-6.0, which was posted in comp.sources.misc, volume 27. [Ed note:] PP is usually used in combination with the ISODE package, which also provides copious documentation for PP. PP itself is "freeware", but ISODE and the PP documentation is not - site licenses are rather pricy. PP is *very* large, and has quite a number of more esoteric functions, such as FAX transmission using the appropriate modems. PP is ideal for large organizations with demanding email requirements (eg: 100s of machines and 1000s of users), where PP would be used as "backbone mail servers", and something simpler on the "client" computers. It does have _substantial_ learning and support requirements, and is *not* suitable for smaller installations. It does, however, shine in large production environments, where policy-based routing, high levels of security, or extensive gatewaying to different transports is required. SVR4 mail: Author AT&T (description written by Tony Hansen, hansen@pegasus.att.com) The System V Release 4 mail system is a domain-capable mail router and delivery program that works in the UUCP zone and on the Internet and that is capable of gatewaying between the two. SVR4 mail supports SMTP, UUCP mail, alias files, forwarding files, mailing list directories, /etc/hosts files, the domain name system, and can also query uucp for neighboring sites, automatically. (System V Release 4.1 also allows batching of multiple messages into a single UUCP transaction, and allows many addresses to be passed with a single message transfer, which can greatly decrease the traffic generated for large mailing lists.) It is also very simple to configure with a reasonable certainty of correctness. It also supports mail-to-pipe and mail-to-file. SVR4 mail uses configuration files to resolve addresses based on their syntax, somewhat similar to sendmail, but using regular expressions and a more easily understood syntax. The set of methods that SVR4 mail uses for resolving local and remote addresses and hosts is configurable and extensible. Questions related to SVR4 mail are usually discussed in comp.mail.misc. SVR4 mail is a standard part of System V Release 4; unfortunately, some vendors have not realized that SVR4 mail is not the same mailer as the SVR3 mail system, and have replaced it with other inferior mail systems. | deliver: Author Chip Salzenberg* <chip@fin!chip@dg_rtp.dg.com> Deliver allows any user to write a shell script that processes all incoming mail messages for that user. The system administrator may also install scripts that process all messages by installing it as the Local Delivery Agent (lmail replacement). The output of a script is a list of mail addresses, files and programs that should receive the message. It has access to each message as it is processed, so the action can be content dependent. The script may also generate automatic replies, like the "vacation" program, or pass along a modified version of the original message. Deliver can be used to construct mail-based services (e.g. automatic mailing list maintenance). It can also be used to filter mail automatically in prearranged ways (e.g. encryption and decryption, tossing junk mail, or vacation notices). Deliver was last posted in comp.sources.reviewed, volume 1. The | current version is 2.1.12. | It can be retrieved from <ftp:ftp.cs.uni-sb.de/pub/mail/deliver> procmail: Author Stephen R. van den Berg* <berg@pool.informatik.rwth-aachen.de> Can be used to create mail-servers, mailing lists, sort your incoming mail into separate folders/files (real convenient when subscribing to one or more mailing lists or for prioritising your mail), preprocess your mail, start any programs upon mail arrival (e.g. to generate different chimes on your workstation for different types of mail) or selectively forward certain incoming mail automatically to someone. Procmail can be used: - and installed by an unprivileged user (for himself only). - as a drop in replacement for the local delivery agent /bin/mail (with biff/comsat support). - as a general mailfilter for whole groups of messages (e.g. when called from within sendmail.cf rules). The accompanying formail program enables you to generate autoreplies, split up digests/mailboxes into the original messages, do some very simple header-munging/extraction, or force mail into mail-format (with leading From line). Also included is a comprehensive mailinglist/archive management system. Since procmail is written entirely in C, it poses a very low impact on your system's resources (under normal conditions, when you don't start other programs/scripts from within it). Procmail was designed to deliver the mail under the worst conditions (file system full, out of swap space, process table full, file table full, missing support files, unavailable executables; it all doesn't matter). Should (in the unlikely event) procmail be unable to deliver your mail somewhere, the mail will bounce back to the sender or reenter the mailqueue (your choice). A recent version can be picked up at various comp.sources.misc archives. The latest version (3.03) can be obtained directly from the ftp-archive at: ftp.informatik.rwth-aachen.de (137.226.225.3) (g)zipped: pub/packages/procmail/procmail.tar.gz <160KB compressed: pub/packages/procmail/procmail.tar.Z <224KB [Ed note: I had noted reported difficulties in integrating procmail with System V and/or smail 2.5. The 2.70 version of Procmail eliminated these difficulties.] mailagent: Author Raphael Manfredi* <ram@acri.fr> The mailagent is yet another mail filter, written in perl, which will let you do anything with your mail. It has all the features you may expect from a filter: mailing lists sorting, forwarding to MTA or to inews, pre-processing of message before saving into folder, vacation mode, etc... It was initially written as an ELM-filter replacement, but has now enough power to also supplant MMDF's .maildelivery. There is also a support for @SH mail hooks, which allows you to automatically distribute patches or software via command mails. The mailagent was designed to make mail filtering as easy as it can be. It is highly configurable and fairly complete. Rules are specified in a lex-like style, with the full power of perl's regular expressions. The automaton supports the notion of mode, and header selection has many magic features built-in, to ease the rule writing process. To give a simple example, the two following rules: Subject: /cron output/ { SAVE cron }; To Cc: dist-users { FORWARD friend@acri.fr; LEAVE }; would save in a folder 'cron' all cron-related mail, and forward mail from the dist-users mailing list to a friend, leaving a copy in the system mailbox for immediate processing... It supports delivery to plain UNIX folder, to MMDF-style folders or to MH folders with built-in unseen sequence updates, as specified in your ~/.mh_profile. It may therefore replace MH's slocal program as well. Mailagent can be dynamically extended (that's the advantage of having it written in perl) with new filtering commands that will behave exactly like built-in ones; this operation being done without changing a single source line in the program itself, of course. It also provides a generic mail server layer, where user-defined commands can be easily plugged in, mailagent taking care of the lower-level stuff. The distribution comes with a set of examples, an exhaustive test suite, and naturally a detailed manual page. It should be noted that the mailagent will work even if your system administrator forbids "| programs" hooks in the ~/.forward, provided you have access to some sort of cron daemon. The mailagent program is available from any comp.source.misc archive and thanks to Christophe Wolfhugel <Christophe.Wolfhugel@grasp.insa-lyon.fr>, from ftp.univ-lyon1.fr (134.214.100.6) under /pub/unix/mail/tools, file mailagent-3.0.tar.gz pathalias: Author Peter Honeyman Pathalias reads the UUCP Map Project maps (they need to be extracted from the postings first) and constructs a database containing the minimum cost route to any machine in the maps. This database can then be used with any mailer that knows how to search the database (eg: smail 2.5, Zmailer?, and some versions of sendmail. Smail 3 comes bundled with pathalias). There were previous versions of this program. You must use pathalias version 10 (latest version), because some map format changes have been made and only pathalias 10 can parse them. If your pathalias doesn't give a syntax error on: echo "file {foo}" | pathalias It's the new one. There were other route-generating programs, but all (as far as I know) are very obsolete, and none run as fast as pathalias (still, which can be rather hard on machines with smallish virtual memory or RAM capacities). pathalias 10 is available from comp.sources.unix archives, volume 22. A patch was just released in comp.sources.unix (vol 25) that addresses an oddity when used with smail (not that I've ever noticed it). uuhosts: Author John Quarterman The "defacto" standard UUCP Map Project map unpacker. Includes a program to arbitrarily view individual map entries. Uuhosts implements trojan horse/virus security by running under a "chroot()" system call. Uuhosts does not appear to be actively maintained, and the last versions that I have inspected were unable to easily compress the maps (a full set of maps is >6000 blocks), had no provision for automatically running pathalias, and will not work with the newest version of cnews. Further, uuhost's header checking is so picky that the slightest change in the map format will cause uuhosts to reject map updates. Use of uuhosts now will require some minor hacking - and this hacking will stretch your knowledge of Bourne shell programming. The last edition, "uuhost4" (version 1.69) appears to have been posted in comp.sources.unix in volume 3, 1986. Do not be confused by Jan-Piet Mons "uuhost 2.0" program posted in alt.sources. This is not a map unpacker. It is just a map viewer, and is a subset of the real uuhosts. unpackmaps: Author Chris Lewis* <clewis@ferret.ocunix.on.ca> Unpackmaps is a superset of the functionality of uuhosts. It obtains its security by doing the map unpacking with a specialized parser that knows the map article format rather than invoking a shar/shell. Compression and pathalias invocation is automatic, correctly takes into account the change date of local configuration files, and will work with the latest Cnews. The newest version of unpackmaps, version 4.1, has been released to comp.sources.misc, and appeared in volume 34. This version is entirely written in C, is considerably faster than unpackmaps 3 or uuhosts, has considerably more features, and will work with Brian Reids PostScript net maps too. unshar: Author Lee Ward, modified by Mark Moraes* <moraes@deshaw.com> | unshar is evolved from getmaps by Lee Ward. It is has a specialized | and limited parser that understands most simple shar formats. It is | capable of automatically unpacking new files from a newsgroup spool | directory, and requires no interaction whatsoever with the news | system. Apart from UUCP maps, it can be used to automatically and | safely unpack shar files from the sources newsgroups. It does not | handle some of the newer, esoteric shar formats that do automatic | uudecodes, etc. Ftp'able from | ftp.cs.toronto.edu:/pub/moraes/unshar.tar.gz. -- Chris Lewis: _Una confibula non sat est_ Phone: Canada 613 832-0541 Latest psroff: FTP://ftp.uunet.ca/distrib/chris_lewis/psroff3.0pl17/* Latest hp2pbm: FTP://ftp.uunet.ca/distrib/chris_lewis/hp2pbm/*